动态 > 活动的内在:该如何发放奖品
浏览量 550 2019年06月21日 掌心科技发布
营销活动的形式一直在不断的进化着,从最开始简单粗暴的摇一摇,到砸金蛋、大转盘、发红包,再到后来的砍价(助力)、积分商城、小游戏。外在形式的丰富了,但内在总是绕不过如何发放奖品。
本文便从发放奖品的规则和安全,和大家分享一下踩过的坑。
在营销活动中,我们为了追求更好的活动效果,又或者受限于成本、库存等原因,会对发放奖品制定一系列规则,这些规则会导致奖品概率不准确。
接下来以表1为例进行举例阐述:
表1 奖品发放需求
库存控制规则,其实也是奖品的均匀发放机制,目的是使奖品不至于过早发放完毕。
1.1 中奖次数
1.2 奖项互斥
1.3 奖项优先级
1.4 奖品真实库存不足
除了主动控制库存,也有真实的库存不足导致了概率不准确。
当“一等奖:手机”全部发放完毕,库存为0。逻辑上程序不再抽取此奖项,在库存为0至库存补充的过程中,如不加控制,抽取另一个“一等奖:电视”的概率,则变成了2.5%÷97.5。
那么这些概率不准确的地方应该如何避免呢?避免概率不准确,其实也是避免库存不足。
当抽中手机时,手机库存为0,不予发放手机,可采取以下两种方案:
在奖品发放中,除了发放规则,更重要的是安全规则的设置,毕竟有利益的地方,就有冲突。
在奖品发放的安全机制中,主要从运维监测、开发规范两个方面进行描述。
运维监测,事实上也是数据监测。
常见的按钮数据、页面数据指向的产品优化。而运维监测,则指向了产品的风控。
1.1 库存监控
1.1.1 监控目的:
a、防止库存消耗过快,活动无法进行。
b、防止恶意攻击等作弊行为,盗刷奖品。
c、防止奖品兑换/抽取失败场景。
1.1.2 监测手段:
库存的余量监控根据库存限制类型不同,监测手段不同:
a、 库存受自身限制类奖品:
即库存数据源来自自身,能根据平台发放奖品数据监测自身库存。
监控方式:奖品库存剩余50%、30%、10%预警。
b、库存受第三方限制类奖品:
即库存数据源来自第三方,常见于积分商城,商城内奖品为接入第三方接口,库存数据不主动推送给接入方。
监控方式:
当涉及到虚拟奖品如流量、话费类,奖品发放失败记录应在某时间段汇总以邮件或其他方式进行提醒,由运营人员进行补发操作。
1.2 增量监控
1.2.1 监控目的
当数据高于平均值或出现极值,考虑是否出现恶意攻击等作弊行为。
1.2.2 监控方式
主要列举增量例子:
1.3 异常行为监控
1.3.1 监控目的:
主要针对违背正常逻辑的行为做监控,考虑是否出现恶意攻击等作弊行为。
1.3.2 监控方式:
此类问题主要去研发、测试、运维人员相关。
2.1 主从服务器
a、实现服务器负载均衡:
在主服务器和从服务器之间实现负载均衡。即可以通过在主服务器和从服务器之间切分处理客户查询的负荷,从而得到更好的客户响应时间。
b、实现数据的异地备份:
定期将数据从主服务器上复制到从服务器上,提高信息安全。
c、提高数据库系统的可用性
数据库复制功能实现了主服务器与从服务器之间数据的同步,当主服务器出现问题时,数据库管理员可以马上让从服务器作为主服务器,用来数据的更新与查询服务。
2.2 接口数据校验
接口传输的数据是否符合规范,防止接口攻击。
2.3 接口调用顺序
如:积分兑换失败时,应先修改兑换状态,再返还积分。
防止先返还积分再修改状态,导致接口被攻击。
2.4 接口调用频率
设置接口调用时间限制,如:游戏中30秒限制使用1次道具,调用接口后,30秒内不得重复调用。
2.5 配置文件、写死代码自检
在测试阶段为了测试便利,常常会修改配置文件或写死某部分代码,容易造成上线时未替换正确的配置文件和代码。
上线阶段也需要检测配置文件是否生效等问题。
2.6 压力测试
对用户量大的程序,是否可达到期望的并发量,接受的接口错误率是多少?当压力过大,可能会导致数据丢失、接口卡死等情况。
奖品发放的相关逻辑非常的多,发放逻辑、监测机制、安全机制每一个都不是简单能够完善的,当无法完全考虑详细时,一定要尽可能有足够多的运维措施和应急预案。
除此之外,不单是奖品发放,其他产品设计中异常流、非功能性需求的考虑深度亦或者是解决能力,也是产品经理进阶不可少的一环,也希望通过这一次简单的分享,能够做到抛转引玉,与大家共同交流。
1
2
3
2024-04-02
4
2024-04-02
5
2024-04-02